Subject: Names in ACTPU/ACTLU

From: David Bryant/HQ/3Com <[email-masked]>
Date: 12 Dec 95 13:29:54 EDT

Sounds like Dave Finnie has a legitimate problem (although implementation 
specific) in the proposal to change the DLC control frames.  It's not actually 
a proposal I favor anyway.

IBM - (don't know who to specifically address this to): 

What's the possibility of getting IBM to add a VTAMLST (Start option as well as 
group/line specific) option that sends the names?  I recognize this would be a 
change to both VTAM and NCP.

Dave Bryant
Director IBM Internetworking  
3Com Corp

---

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 12 Dec 1995 11:59:00 -0500

In message "Names in ACTPU/ACTLU", David Bryant writes:

>Guys - 
>
>Let me also express my desire to see this information passed on ACTLU and 
>ACTPU.  This information is required in all cases where SNA Boundary functions 
>are being extended via technologies like: APPN/DLUr, BAN, RFC1490, and DLSw.  I 
>We need to carry some indicator to VTAM/NCP BF to let them know we'd like the 
>info.   I can think of a couple of options:  
>
>1). We could use a bit in XID0 byte 0, bit 4-7 to indicate desire for the name.
>But I realize, as Jim indicates, we can't always count on an XID exchange. 
>(This probably can be avoided in most technologies which provide local LLC 
>termination).  But  alternatively, 

Format 3 XID is perhaps not mandated by the PU 2.0 specification, but that
is in part because there is no industry standard specification for the
behavior of a PU 2.0 with the exception of the relevant portions of
SC30-3112, which pre-dates the introduction of format 3 XID.  Format 3 XID
is mandatory for all nodes supporting independent LUs.  It is also mandatory
for a node supporting DDDLU.  I therefore would accept a solution which
required adding a bit somewhere in bytes 10-14 of the format 3 XID which
indicates that the sender may not understand all possible control vectors,
but promises not to reject an ACTPU or an ACTLU which contains one or more
control vectors after the fixed portion.

XID exchange is mandatory in all data link implementations except SDLC 
leased line and X.25 permanent virtual circuits, and it is optional there.
There is an existing sysdef parameter in the NCP, XID=YES, which activates
this on SDLC leased lines and X.25 PVCs.  Since the industry has added
support for APPN to its product lines, most of the rest of us also have an
equivalent capability in our SDLC primary link station implementations.  I
therefore conclude that there is no need for any
new sysdef option in the NCP BF, or probably in most of our boundary links,
only the need to understand an additional bit in the format 3 XID response
from a PU 2 or T2.1.

>2). We can count on a SNRM/SABM|E-UA exchange.  It is possible for us to 
>define new frames in the control field portion of the DLC.  Think of these
>frames as SNRMn, SABMn/SABMEn, and UAn.
>Where the 'n' implies desire for a name on ACTPU and ACTLU.
>-The trick to this approach is that the sender will need to know ahead of time 
>whether these frames can be sent to the Boundary Function in question.  So 
>this would require sysdef on the part of the sender.   But I think it avoids 
>sysdef on VTAM and NCP.  This is, of course, of crucial importance to IBM 
>and we need their help to make this work.   So making it easier on IBM seems 
>a reasonable compromise to me. 

I do not understand this approach.  The BF is the sender of the mode setting
command, and therefore is the component which would need the sysdef changes.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcarsf1f!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Nortel.               |